local echo (7/7): Support simplified version of local echo #1453

PIG208 · 2025-04-01T22:03:48Z

Stacked atop #1472.

(This branch can be used to preview the full implementation)

screenshots

message sent	got message event

message failed to send	message content tapped	recipient headers

PIG208 · 2025-05-23T05:09:53Z

I temporarily removed the last two commits because the confirmation dialog requires us to rework the implementation and tests more.

chrisbobbe

Thanks! Here's another round of review—it includes some comments I wrote yesterday on those commits that you temporarily removed in this revision, and they may or may not still apply to your new versions of those commits :)

chrisbobbe · 2025-05-22T22:45:59Z

lib/model/message_list.dart

@@ -163,6 +191,7 @@ mixin _MessageSequence {
  /// Either the bottom slices of both [items] and [messages] are empty,
  /// or the first item in the bottom slice of [items] is a [MessageListMessageItem]
  /// for the first message in the bottom slice of [messages].
+  // TODO(#1453) update this in the context of outbox messages.


#1453 is a PR number (this one) 🙂; did you mean to mention an issue?

Ah, this is just a TODO for myself to update this dart doc, since we can have outbox-message related items in the list.

chrisbobbe · 2025-05-22T23:34:28Z

lib/model/message_list.dart

+    // This loop relies on the assumption that all items that follow
+    // the last [MessageListMessageItem] are derived from outbox messages.
+    // If there is no [MessageListMessageItem] at all,
+    // this will end up removing end markers.


Is the second sentence still true/necessary after c5e6957?

This should end up removing all items, but that's less relevant now because we used to need to restore the end markers at the end. Updating it to describe the behavior accurately.

chrisbobbe · 2025-05-22T23:58:17Z

lib/model/message_list.dart

    // TODO insert in middle instead, when appropriate
    _addMessage(message);
+    if (event.localMessageId != null) {
+      final localMessageId = int.parse(event.localMessageId!);
+      // [outboxMessages] is epxected to be short, so removing the corresponding


nit: "expected"

chrisbobbe · 2025-05-23T00:02:07Z

lib/widgets/message_list.dart

-                    child: Text(message.senderFullName, // TODO(#716): use `store.senderDisplayName`
+                    child: Text(message is Message
+                        ? store.senderDisplayName(message as Message)
+                        : store.userDisplayName(message.senderId),


Is there some of this that can go in a separate commit? I notice it deletes a TODO for a separate issue.

chrisbobbe · 2025-05-23T00:05:56Z

lib/widgets/message_list.dart

+/// A placeholder for Zulip message sent by the self-user.
+///
+/// See also [OutboxMessage].
+class OutboxMessageWithPossibleSender extends StatelessWidget {


nit: how about

/// A "local echo" placeholder for a Zulip message to be sent by the self-user.

so it doesn't look like it could apply to messages that were sent in the past.

chrisbobbe · 2025-05-23T00:06:12Z

lib/widgets/message_list.dart

+          _SenderRow(message: message, showTimestamp: false),
+        Padding(
+          padding: const EdgeInsets.symmetric(horizontal: 16),
+          // This is adapated from [MessageContent].


nit: "adapted"

Oh I see. Looks like I fixed in the wrong commit last time.

chrisbobbe · 2025-05-23T00:45:50Z

test/model/message_list_test.dart

+    test('not in narrow', () => awaitFakeAsync((async) async {
+      await prepare(narrow: eg.topicNarrow(stream.streamId, 'topic'), stream: stream);
+      await prepareMessages(foundOldest: true, messages:
+        List.generate(30, (i) => eg.streamMessage(stream: stream, topic: 'topic')));
+      await prepareOutboxMessages(count: 5, stream: stream);
+      check(model).outboxMessages.isEmpty();
+
+      async.elapse(kLocalEchoDebounceDuration);
+      checkNotNotified();
+      check(model).outboxMessages.isEmpty();
+    }));


The prepareOutboxMessages defaults to a topic 'some topic', which is indeed different from 'topic'. But that's not easy to see locally; how about passing an explicit value that's easy to compare with 'topic' to see that it's different.

chrisbobbe · 2025-05-23T02:42:38Z

lib/widgets/message_list.dart

+      case OutboxMessageState.waitPeriodExpired:
+        final isComposeBoxOffered =
+          MessageListPage.ancestorOf(context).composeBoxState != null;
+        handleTap = isComposeBoxOffered ? () => _handlePress(context) : null;


nit: _handleTap rather than _handlePress, I think, for consistency with GestureDetector.onTap

Also, to be consistent with edit-message, let's apply the handler only to the message content, not also the sender row.

chrisbobbe · 2025-05-23T02:49:04Z

lib/widgets/message_list.dart

+      case OutboxMessageState.failed:
+      case OutboxMessageState.waitPeriodExpired:


Is it intentional to show "MESSAGE NOT SENT" in the waitPeriodExpired state? I think this could cause a confusing symptom like #1525, where the message has actually been sent (or will be) but we say it hasn't.

In v0.0.29 we'd enter this state even if we got a success response from the send request, if the event didn't then show up. I suspect that's what happened in the report in #1525.

In the current revision of this PR, a success response will put the outbox-message into waiting state indefinitely, until the event arrives. I think showing this is OK if we've gotten neither the event nor a response from the request.

(The exact status in that case is more like "tried sending the message, it's been a while, haven't heard any response yet, so it may or may not have made it through, up to you if you want to retry". Not sure there's a good concise way to communicate that.)

chrisbobbe · 2025-05-23T03:11:08Z

lib/widgets/message_list.dart

+      case OutboxMessageState.waiting:
+        final designVariables = DesignVariables.of(context);
+        return Padding(
+          padding: const EdgeInsetsGeometry.only(top: 1.5, bottom: 0.5),


_OutboxMessageStatusRow is similar enough to _EditMessageStatusRow that I think it makes sense to be consistent between them in how we do this padding.

Experimentally, 0.5px on the bottom looks odd to me, as though it's meant to touch the bottom—and also the left and right edges of the screen—but it accidentally doesn't:

0.5px below 4px below (edit-message)

I know your implementation follows the Figma, but in this case I would just do what we do for edit-message; the code is also simpler that way.

While we have adjusted the debounce timeout in the more recent version #1472, I think the issue with the layout shift caused by the loading indicator still exists (#1453 (comment)), at least for messages that don't have fancy formatting.

We have 4px total in message content's bottom padding, and the height of the progress bar is 2px. How about moving the progress bar to the top half of the bottom padding, so that there is 2px instead of 0.5px after it? Meanwhile, we can adjust the bottom padding of the edit status row to be 2px so that they are consistent.'

2px below 2px below (edit-message)

Note that the local echo indicator sits inside the bottom padding of the message content, and the one for edit-message doesn't. I think this is fine since there is label that doesn't fit within the padding for edit-message anyway.

Sure, SGTM.

gnprice

I see the review cycles with Chris aren't yet complete, but I wanted to take a look in so you have a review for tomorrow. I made my way through the first four commits after #1472 (which this PR is stacked atop a version of):
67e5e1f msglist: Remove trailingWhitespace
827939a test [nfc]: Extract {dm,stream}OutboxMessage helpers
363024a msglist test [nfc]: Make checkInvariant compatible with MessageBase
b0dc888 msglist [nfc]: Extract _addItemsForMessage

and looked at part of the main model commit:
5579e00 msglist: Add and manage outbox message objects in message list view

Generally this looks good; comments below, all more or less small. Probably the priority for tomorrow is those two final commits that were temporarily removed (#1453 (comment)).

gnprice · 2025-05-26T05:16:10Z

lib/widgets/message_list.dart

        },
-        if (trailingWhitespace != null && item.isLastInBlock) SizedBox(height: trailingWhitespace!),


Hmm, this feels like it makes things pretty crowded just above a recipient header.

msglist: Remove trailingWhitespace This 11px whitespace can be traced back to 311d4d56e in 2022, and is not present in the Figma design. It was there to match the web design while prototyping the app.

I just spent a few minutes looking around in Figma and didn't find an example of a message list for an interleaved view, so one with messages followed by recipient headers. Do you know of one?

Probably it would be good to refine this spacing somehow, e.g. by skipping it when followed by the end of the feed rather than a recipient header. But let's not just take it out entirely. (And so for this PR, probably leave it the way it is, behavior-wise.)

It looks like in main it's already a constant. So the code could be simplified by propagating that constant down to this line, and therefore still removing the trailingWhitespace field.

The only ones I have seen are in design-process drafts, like this one. I will turn this into an NFC for this PR.

gnprice · 2025-05-26T05:22:13Z

test/model/narrow_test.dart

      check(narrow.containsMessage(
-        _TestDmMessage(allRecipientIds: [1, 2]))).isTrue();
+        eg.dmOutboxMessage(from: user1, to: [user2]))).isTrue();


This check's data is inconsistent: the narrow says selfUserId is 2, but the message says it's 1.

(I guess this was present in the version already in main and this change is NFC. But the from/to makes it more apparent than the allRecipientIds[0] behavior did. That's a good thing about the new helpers. 🙂)

Hmm, right. The test was not set up correctly. Adding a prep commit (ideally we would change the old helpers to use from/to, but I kept it minimal just so we can fix the test data), so that we can keep the refactor NFC.

gnprice · 2025-05-26T05:30:52Z

test/model/message_list_test.dart

+    if (message is Message) {
+      check(model.store.messages)[message.id].isNotNull().identicalTo(message);
+    } else if (message is OutboxMessage) {
+      check(message).hidden.isFalse();
+      check(model.store.outboxMessages)[message.localMessageId].isNotNull().identicalTo(message);
+    } else {
+      assert(false);
+    }


This first check can become two separate loops, making the logic of both of them simpler.

(Arguably it should have been a separate loop in the first place — it's checking something logically fairly different from what the rest of this loop body is checking. But that had less impact when it was one line.)

gnprice · 2025-05-26T05:32:25Z

test/model/message_list_test.dart

@@ -2151,17 +2684,27 @@ void checkInvariants(MessageListView model) {
    check(model).fetchOlderCoolingDown.isFalse();
  }

-  for (final message in model.messages) {
-    check(model.store.messages)[message.id].isNotNull().identicalTo(message);
+  final allMessages = [...model.messages, ...model.outboxMessages];


Looking through the existing checks on model.messages, here's another that should gain a counterpart for model.outboxMessages:

check(isSortedWithoutDuplicates(model.messages.map((m) => m.id).toList())) .isTrue();

The outbox messages should be ordered by localMessageId.

gnprice · 2025-05-26T05:40:35Z

lib/model/message_list.dart

      if (!messagesSameDay(prevMessageItem.message, message)) {
        items.add(MessageListDateSeparatorItem(message));
        canShareSender = false;
      } else {
-        canShareSender = (prevMessageItem.message.senderId == message.senderId);
+        canShareSender = prevMessage.senderId == message.senderId;


nit: keep this using prevMessageItem.message rather than prevMessage

The previous item is the thing that directly matters for whether this next item should share its sender row. It's also what's used a few lines above in the messagesSameDay call, so that keeps the logic a bit more internally coherent to read.

gnprice · 2025-05-26T07:03:31Z

lib/model/message_list.dart

+  ///
+  /// Usually this should not have that many items, so we do not anticipate
+  /// performance issues with unoptimized O(N) iterations through this list.
+  final List<OutboxMessage> outboxMessages = [];


This adds some overhead in magnitude of O(1) (where the constant is the number of outbox messages in a view, expected to be small) on message event handling.

That is not what the word "constant" means 🙂

Instead can say:

This adds some overhead on message-event handling, linear in the number of outbox messages in a view. We rely on that number being small.

Or could say something like "O(k), where there are k outbox messages in the view".

gnprice · 2025-05-26T07:06:39Z

lib/model/message_list.dart

+    required super.showSender,
+    required super.isLastInBlock,
+  }) : content = ZulipContent(nodes: [
+    ParagraphNode(links: [], nodes: [TextNode(message.contentMarkdown)]),


Suggested change

ParagraphNode(links: [], nodes: [TextNode(message.contentMarkdown)]),

ParagraphNode(links: null, nodes: [TextNode(message.contentMarkdown)]),

See the doc on the links field:

/// A list of all [LinkNode] descendants. /// /// An empty list is represented as null. /// […]

gnprice · 2025-05-26T07:09:37Z

lib/widgets/message_list.dart

@@ -718,7 +718,11 @@ class _MessageListState extends State<MessageList> with PerAccountStoreAwareStat
        return MessageItem(
          key: ValueKey(data.message.id),
          header: header,
-          trailingWhitespace: 11,
+          item: data);
+      case MessageListOutboxMessageItem():


This implements minimal support to display outbox message message item widgets in the message list, without indicators for theirs states. Retrieving content from failed sent requests and the full UI are implemented in a later commit.

Is there — ah, I guess that was in the commits you temporarily removed as mentioned at #1453 (comment) .

This 11px whitespace can be traced back to 311d4d5 in 2022. While this is not present in the Figma design, it would be a good idea to refine it in the future. See discussion: zulip#1453 (comment)

This changes the bottom padding from 4px to 2px, to match the later added status row for outbox messages. See discussion: zulip#1453 (comment)

Different from the Figma design, the bottom padding below the progress bar is changed from 0.5px to 2px, as discussed here: zulip#1453 (comment) Fixes: zulip#1441

This changes the bottom padding from 4px to 2px, to match the later added status row for outbox messages. See discussion: zulip#1453 (comment)

Different from the Figma design, the bottom padding below the progress bar is changed from 0.5px to 2px, as discussed here: zulip#1453 (comment) Fixes: zulip#1441

PIG208 · 2025-05-27T01:33:25Z

Thanks for the reviews! Pushed an update, this time with the commits I removed last time, with a bunch of prep commits. I also went through this PR's interaction with middleMessage/middleItem, and implemented the behavior discussed in a prior call with Greg, making sure that middleItem points to MessageListOutboxMessageItem in certain condition (the docs on middleItem has been updated to reflect the behavior I intended and implemented).

PIG208 · 2025-05-27T01:35:21Z

Some visual changes in this update:

screenshots

The error message for discarding draft on restoring a message not sent is tentative:

When you restore a message not sent, the content that was previously in the compose box is discarded.

The bottom padding of the status row has changed:

2px below	2px below (edit-message)

from #1453 (comment)

gnprice · 2025-05-28T00:34:14Z

Thanks for the revision! The changes related to my review at #1453 (review) all look good, and the initial 5 commits all look good to me now:
c1f6b8d msglist [nfc]: Make trailingWhitespace a constant
0b12cab narrow test: Make sure sender is selfUser in tests
e1fa25e test [nfc]: Extract {dm,stream}OutboxMessage helpers
33a2e0d msglist test [nfc]: Make checkInvariant compatible with MessageBase
93d89a6 msglist [nfc]: Extract _addItemsForMessage

I haven't yet read the subsequent commits in full:
5488a7a msglist: Use store.senderDisplayName for sender row
d64698e msglist [nfc]: Make _SenderRow accept MessageBase
9c0b955 msglist: Add and manage outbox message objects in message list view
6604cf4 compose [nfc]: Make confirmation dialog message flexible
b2d6c50 compose test [nfc]: Move some edit message helpers out of group
cfbbdc0 compose [nfc]: Update string to mention "edit" in name and description
c8295ae msglist: Adjust edit-message status row bottom padding
1fa9f24 msglist: Support retrieving failed outbox message content

@chrisbobbe will be taking over this PR; I'll leave those latter commits until after he's made a pass through them.

chrisbobbe · 2025-05-28T01:58:40Z

Great! Merging those first five, with a small commit-message tweak:

$ git range-diff upstream 93d89a6a a4c564b1c
1:  c1f6b8dca = 1:  86f62c9b1 msglist [nfc]: Make trailingWhitespace a constant
2:  0b12cab63 ! 2:  75f0debbf narrow test: Make sure sender is selfUser in tests
    @@ Metadata
     Author: Zixuan James Li <[email protected]>
     
      ## Commit message ##
    -    narrow test: Make sure sender is selfUser in tests
    +    narrow test: Make sure sender is selfUser for outbox DM messages
    +
    +    [chris: expanded commit-message summary line]
    +
    +    Co-authored-by: Chris Bobbe <[email protected]>
     
      ## test/model/narrow_test.dart ##
     @@ test/model/narrow_test.dart: void main() {
3:  e1fa25e8f = 3:  815b9d2f4 test [nfc]: Extract {dm,stream}OutboxMessage helpers
4:  33a2e0d04 = 4:  2829bd847 msglist test [nfc]: Make checkInvariant compatible with MessageBase
5:  93d89a6ac = 5:  a4c564b1c msglist [nfc]: Extract _addItemsForMessage

This 11px whitespace can be traced back to 311d4d5 in 2022. While this is not present in the Figma design, it would be a good idea to refine it in the future. See discussion: #1453 (comment)

This is where the progress bar for outbox messages will go, so this is for consistency with that. Discussion: zulip#1453 (comment)

This is where the progress bar for outbox messages will go, so this is for consistency with that. Discussion: zulip#1453 (comment) [chris: fixed to maintain 4px bottom padding in the common case where the progress bar is absent] Co-authored-by: Chris Bobbe <[email protected]>

chrisbobbe · 2025-05-28T21:27:04Z

And I've sent revised versions of the next chunk, in #1535.

This is where the progress bar for outbox messages will go, so this is for consistency with that. Discussion: zulip#1453 (comment) [chris: fixed to maintain 4px bottom padding in the common case where the progress bar is absent] Co-authored-by: Chris Bobbe <[email protected]>

This adds some overhead on message-event handling, linear in the number of outbox messages in a view. We rely on that number being small. We add outboxMessages as a list independent from messages on _MessageSequence. Because outbox messages are not rendered (the raw content is shown as plain text), we leave the 1-1 relationship between `messages` and `contents` unchanged. When computing `items`, we now start to look at `outboxMessages` as well, with the guarantee that the items related to outbox messages always come after those for other messages. Look for places that call `_processOutboxMessage(int index)` for references, and the changes to `checkInvariants` on how this affects the message list invariants. `addOutboxMessage` is similar to `handleMessage`. However, outbox messages do not rely on the fetched state, i.e. they can be synchronously updated when the message list view was first initialized. This implements minimal support to display outbox message message item widgets in the message list, without indicators for theirs states. Retrieving content from failed sent requests and the full UI are implemented in a later commit. Co-authored-by: Chris Bobbe <[email protected]>

Issue zulip#720 is superseded by zulip#1441, in which we'll still clear the compose box when the send button is tapped. (We'll still preserve the composing progress in case the send fails, but we'll do so in an OutboxMessage instead of within the compose input in a disabled state.)

Issue zulip#720 is superseded by zulip#1441, and these don't apply... I guess with the exception of a note on how a generic "x" button could be laid out, so we leave that.

Different from the Figma design, the bottom padding below the progress bar is changed from 0.5px to 2px, as discussed here: zulip#1453 (comment) Fixes: zulip#1441 Co-authored-by: Chris Bobbe <[email protected]>

chrisbobbe · 2025-05-30T21:30:15Z

OK, and now rebased with a revision ready for review! This is stacked atop #1538, which is a separate PR because it's a substantial commit.

This was referenced Apr 1, 2025

local echo (1/n): Add API support for local_id/local_message_id and queue_id #1454

Merged

local echo (2/n): Rearrange queueId and sendMessage within store #1455

Merged

PIG208 changed the title ~~Support simplified version a local echo (n/n)~~ Support simplified version of local echo (n/n) Apr 1, 2025

PIG208 changed the title ~~Support simplified version of local echo (n/n)~~ locale echo (n/n): Support simplified version of local echo Apr 1, 2025

PIG208 force-pushed the pr-echo branch from 8d1f962 to b73dc22 Compare April 1, 2025 22:14

PIG208 changed the title ~~locale echo (n/n): Support simplified version of local echo~~ local echo (n/n): Support simplified version of local echo Apr 2, 2025

PIG208 mentioned this pull request Apr 3, 2025

local echo (3/n): Pull out MessageBase #1463

Merged

PIG208 force-pushed the pr-echo branch 16 times, most recently from 988c615 to f297a65 Compare April 15, 2025 01:45

PIG208 marked this pull request as ready for review April 15, 2025 01:49

PIG208 force-pushed the pr-echo branch 5 times, most recently from aa81e2f to 28d545f Compare April 17, 2025 18:49

PIG208 changed the title ~~local echo (n/n): Support simplified version of local echo~~ local echo (6/6): Support simplified version of local echo Apr 17, 2025

PIG208 force-pushed the pr-echo branch from 9c2c403 to 1f83717 Compare May 23, 2025 05:08

chrisbobbe reviewed May 23, 2025

View reviewed changes

gnprice mentioned this pull request May 24, 2025

Issues with message state #1525

Open

gnprice reviewed May 26, 2025

View reviewed changes

PIG208 force-pushed the pr-echo branch from 1f83717 to f13f44e Compare May 27, 2025 01:22

PIG208 force-pushed the pr-echo branch from f13f44e to 1fa9f24 Compare May 27, 2025 01:31

chrisbobbe mentioned this pull request May 28, 2025

local echo (6.5/7): Revised prep commits for local echo #1535

Merged

chrisbobbe mentioned this pull request May 30, 2025

local echo (6.75/7): Revised commit for local echo (sans retrieving failed outbox content) #1538

Open

PIG208 and others added 5 commits May 30, 2025 14:27

compose [nfc]: Remove obsoleted TODO(zulip#720)s

3b9366e

Issue zulip#720 is superseded by zulip#1441, and these don't apply... I guess with the exception of a note on how a generic "x" button could be laid out, so we leave that.

compose [nfc]: Expand a comment to include an edge case

d56e20f

msglist: Support retrieving failed outbox message content

419e17b

Different from the Figma design, the bottom padding below the progress bar is changed from 0.5px to 2px, as discussed here: zulip#1453 (comment) Fixes: zulip#1441 Co-authored-by: Chris Bobbe <[email protected]>

chrisbobbe force-pushed the pr-echo branch from 1fa9f24 to 419e17b Compare May 30, 2025 21:29

		case OutboxMessageState.failed:
		case OutboxMessageState.waitPeriodExpired:

		},
		if (trailingWhitespace != null && item.isLastInBlock) SizedBox(height: trailingWhitespace!),

	ParagraphNode(links: [], nodes: [TextNode(message.contentMarkdown)]),
	ParagraphNode(links: null, nodes: [TextNode(message.contentMarkdown)]),

local echo (7/7): Support simplified version of local echo #1453

Are you sure you want to change the base?

local echo (7/7): Support simplified version of local echo #1453

Uh oh!

Conversation

PIG208 commented Apr 1, 2025 • edited by gnprice Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PIG208 commented May 23, 2025

Uh oh!

chrisbobbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PIG208 May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PIG208 commented May 27, 2025

Uh oh!

PIG208 commented May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gnprice commented May 28, 2025

Uh oh!

chrisbobbe commented May 28, 2025

Uh oh!

chrisbobbe commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

PIG208 commented Apr 1, 2025 •

edited by gnprice

Loading

PIG208 May 26, 2025 •

edited

Loading

PIG208 commented May 27, 2025 •

edited

Loading

chrisbobbe commented May 28, 2025 •

edited

Loading